feat(traffic-guardian): add runtime monitoring skill baselines#217
Conversation
|
pending agent tests |
davida-ps
force-pushed
the
codex/runtime-traffic-guardian-specs
branch
from
8b61cc5 to
6ad3b1f
Compare
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
| "hermes": { | ||
| "emoji": "TG", | ||
| "category": "security", |
There was a problem hiding this comment.
Should we update the release catalog builder to read the new hermes/nanoclaw/picoclaw metadata instead of .openclaw.emoji/.openclaw.category, since this file lacks openclaw and chained jq lookup will fail during public/skills/index.json generation? (Also consider normalizing the builder or adding an openclaw alias to satisfy SkillMetadata’s string emoji/category shape.)
Finding type: Breaking Changes | Severity: 🔴 High
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents:
Before applying, verify this suggestion against the current code. In
skills/hermes-traffic-guardian/skill.json around lines 60-62 (the top-level `hermes`
block defining `emoji` and `category`), the manifest no longer provides an `openclaw`
object, but the catalog builder’s jq lookup expects `.openclaw.emoji` and
`.openclaw.category` and will fail during `public/skills/index.json` generation. Fix by
either adding an `openclaw` alias object that mirrors the existing `hermes.emoji` and
`hermes.category`, or (preferably) updating the builder to normalize metadata by
platform by falling back to `<platform>.emoji`/`<platform>.category` when `openclaw` is
absent, while still producing the string fields required by `SkillMetadata`. Ensure the
published catalog generation no longer errors when a skill uses the new `hermes`
metadata shape.
| "nanoclaw": { | ||
| "mcp_tools": [ | ||
| "clawsec_traffic_status", | ||
| "clawsec_traffic_findings", | ||
| "clawsec_traffic_check_config" |
There was a problem hiding this comment.
Since this manifest only defines nanoclaw but builders expect SkillJson.openclaw.{emoji,category,triggers} and read .openclaw.emoji/.openclaw.category, populate-local-skills.sh and the deploy job will serialize emoji/category as null and make public/skills/index.json diverge from SkillMetadata — should we add the missing openclaw metadata here or update the builders/schema to honor platform before publishing the traffic-guardian skills?
Finding type: Type Inconsistency | Severity: 🟢 Low
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents:
Before applying, verify this suggestion against the current code. In
skills/nanoclaw-traffic-guardian/skill.json around lines 72-76, the manifest defines
only the `nanoclaw` block and omits the required `openclaw` metadata
(`SkillJson.openclaw.emoji` and `SkillJson.openclaw.category`, and any required
`SkillJson.openclaw.triggers` fields per the contract). Add an `openclaw` section to
this file with valid `emoji` and `category` values (and `triggers` if required) so
scripts/populate-local-skills.sh and the deploy job can stop serializing them as null
and the generated public/skills/index.json matches SkillMetadata. If you cannot
determine the correct category/triggers, pick the closest existing values used by other
published skills in the repo and ensure the schema validation passes.
1 participant
User description
Summary
Testing
python3 utils/validate_skill.py skills/openclaw-traffic-guardianpython3 utils/validate_skill.py skills/hermes-traffic-guardianpython3 utils/validate_skill.py skills/nanoclaw-traffic-guardianpython3 utils/validate_skill.py skills/picoclaw-traffic-guardianjq empty skills/openclaw-traffic-guardian/skill.json skills/hermes-traffic-guardian/skill.json skills/nanoclaw-traffic-guardian/skill.json skills/picoclaw-traffic-guardian/skill.jsonnpm run gen:wiki-llmsnpm run buildNotes
These packages intentionally do not implement proxy runtime code yet. They reserve platform-specific landing zones for builders while documenting the safety contract: opt-in, detect-and-log, no automatic system CA install, no global proxy mutation, and no blocking in the first implementation.
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Document new runtime traffic guardian spec baselines for OpenClaw, Hermes, NanoClaw, and Picoclaw so each platform reserves metadata, SBOM placeholders, safety contracts, and SPEC/README guidance for future proxy builders. Highlight the new runtime traffic monitoring capability in the README feature matrix and multilingual wiki indexes/modules so reviewers understand the architectural purpose of the guard family.
skill.json,SKILL.md,SPEC.md, and placeholder directories so each platform has a safe opt-in landing zone for future proxy runtime work.Modified files (34)
Latest Contributors(1)
runtime-traffic-guardian-baselinemodule page to explain how runtime traffic monitoring slots into the ClawSec roadmap.Modified files (14)
Latest Contributors(2)